Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: not panic in destructor #203

Merged
merged 1 commit into from
Jan 9, 2020
Merged

fix: not panic in destructor #203

merged 1 commit into from
Jan 9, 2020

Conversation

zhangli-pear
Copy link
Contributor

release_resource should not panic. Because with_thread_data may return a ThreadData on the stack, and it's empty.

@zhangli-pear
Copy link
Contributor Author

zhangli-pear commented Jan 6, 2020

following code can reproduce the problem if deadlock_detection feature was enabled.

use std::thread;
use parking_lot::RwLock;

struct Bar(RwLock<()>);

impl Drop for Bar {
    fn drop(&mut self) {
        let _n = self.0.write();
    }
}

thread_local! {
    static B: Bar = Bar(RwLock::new(()));
}

fn main() {
    thread::spawn(|| {
        let a = RwLock::new(());
        let _a = a.read();

        B.with(|_| ());
    }).join().unwrap();
}

@Amanieu
Copy link
Owner

Amanieu commented Jan 8, 2020

I can't reproduce the panic with your example code. Are you sure you are using the latest version of parking_lot?

@zhangli-pear
Copy link
Contributor Author

I can't reproduce the panic with your example code. Are you sure you are using the latest version of parking_lot?

Did you enable deadlock_detection feature?
I'm using 0.9.0 in my project, but latest version is the same.

@Amanieu
Copy link
Owner

Amanieu commented Jan 8, 2020

Yes I enabled deadlock_detection. However no matter how I run your code, I can't get it to panic.

@Amanieu
Copy link
Owner

Amanieu commented Jan 8, 2020

Can you try deleting your Cargo.lock to see if this helps?

@quininer
Copy link

quininer commented Jan 8, 2020

This seems to happen only on macOS, it is same issue as #114.

@Amanieu
Copy link
Owner

Amanieu commented Jan 8, 2020

Right I think I know what the problem is. Basically, the internal ThreadData in parking_lot is getting dropped before the RwLock, which causes all sorts of issues. I'll need to re-read the code to figure out all the implications.

@quininer
Copy link

quininer commented Jan 8, 2020

use std::thread;
use parking_lot::RwLock;

struct Bar(RwLock<()>);

impl Drop for Bar {
    fn drop(&mut self) {
        let _n = self.0.write();
    }
}

thread_local! {
    static B: Bar = Bar(RwLock::new(()));
}

fn main() {
    thread::spawn(|| {
        B.with(|_| ());

        let a = RwLock::new(());
        let _a = a.read();
    }).join().unwrap();
}

reversing init order of tld can make it reproduce on linux.

@Amanieu
Copy link
Owner

Amanieu commented Jan 8, 2020

I think a more general solution is needed here: the deadlock detector needs to be able to handle threads that have exited while still holding leaked locks.

@zhangli-pear
Copy link
Contributor Author

I think a more general solution is needed here: the deadlock detector needs to be able to handle threads that have exited while still holding leaked locks.

maybe not using thread_local?

@Amanieu
Copy link
Owner

Amanieu commented Jan 9, 2020

Actually after reviewing the code, I'm just going to go with your solution.

@Amanieu
Copy link
Owner

Amanieu commented Jan 9, 2020

bors r+

bors bot added a commit that referenced this pull request Jan 9, 2020
203: fix: not panic in destructor r=Amanieu a=zhangli-pear

`release_resource` should not panic. Because `with_thread_data` may return a `ThreadData` on the stack, and it's empty.



Co-authored-by: zhangli.pear <zhangli.pear@bytedance.com>
@bors
Copy link
Contributor

bors bot commented Jan 9, 2020

@bors bors bot merged commit 2afab63 into Amanieu:master Jan 9, 2020
Amanieu added a commit that referenced this pull request Jan 9, 2020
Amanieu added a commit that referenced this pull request Apr 10, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants